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System  Acquisition  Approach  -1 

“We  Got  it  Covered”  Approach 


What  software?  I  am  buying  a 
system  -  my  contractor  will 
take  care  of  all  of  the 
implementation  issues! 
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b.  Cariic^ic  Mellon 
~  Software  Engineering  institute 

System  Acquisition  Approach  -2 


“Let’s  Cross  that  Bridge  When  We  Come  to  It”  Approach 


Software  is  inherently 
flexible  -  so  define  the  rest 
of  the  system  first  and  then 
we  can  define  and  build  the 
software 
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System  Acquisition  Approach  -3 

“Attack  the  High  Risk  Issues  at  the  Outset”  Approach 


Software  poses  major 
system  risk  -  give  software 
issues  full  consideration 
and  adequately  address 
them  from  the  start 
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Purpose  of  the  Guidelines 

Help  project  managers  select  and  defend  acquisition 
strategies  that  explicitiy  consider  and  mitigate  the 
software  risks  in  their  software-intensive  system 
acquisition 

•  Provide  a  framework  for  effectiveiy  reasoning  about 
the  software  risks  in  the  project 

•  Provide  the  insights  necessary  to  mitigate  those 
risks  in  design  of  the  project’s  acquisition  strategy 

•  Create  a  shared  understanding  of  why  specific 
strategies  have  been  seiected  from  among  the 
myriad  of  possibilities 
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To  Mitigate  Software  Risks 

Profile  the  software  risk  in  the  project  early  -  and 
continuously  -  so  that  stakeholders  can  make 
reasonable  mitigation  decisions 

Create  -  and  update  -  the  program’s  acquisition 
strategy  based  on  an  understanding  of  the  program’s 
exposure  to  software  risk 

Reason  about  and  defend  the  efficacy  of  a  given 
acquisition  strategy  based  on  its  ability  to  mitigate  the 
software  risk 
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Determining  Exposure  to 
Software  Risk 

A  primary  concern  in  acquisition  planning  is 
understanding  the  degree  to  which  software 
components  in  the  system  pose  risk. 

The  level  of  software  risk  depends  on 

•  The  amount  of  software  in  the  system 

•  The  importance  of  software  performance  to  system 
operation 

«  The  precedence  or  difficulty  of  a  given  software 
component  to  build  and/or  integrate  with  other 
system  component 
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System  Software  Risk  Elements 


Scale  of  Software 

Software  is  an 
insignificant  portion 
of  system 

Dependence  on  Software 

Software  is  the 
system 

Little  dependence 

-  Mission  not  limited  by 
software 

-  Minimal  consequences. 

Complexity  of  Software 

Very  dependent 

-  Mission  failure  likely 
from  software  failure. 

-  Severe 
consequences 

Low  complexity 

High  complexity 

- ^  .  ..  .  . 

Low  risk  - ►  High  Risk 
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System  Software  Risk  Elements 

Scale  of  Software 


- T" 

Software  is  an  Program  A 

Software  is  the 

insignificant  portion 

system 

of  system 

Dependence  on  Software 

I 


Little  dependence  Program  A  ^ery  dependent 


-  Mission  not  limited  by 

-  Mission  failure  likely 

software 

from  software  failure. 

-  Minimal  consequences. 

-  Severe 

consequences 

Complexity  of  Software 

1 


Low  complexity  Program  A  High  complexity 

The  arrows  represent  the  judgment 
of  the  program  manager 
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Elements  of  Software  Risk 


Lifecycle  Elements 


Programmatic  Elements 


Software  Elements 


The  level  of  software 
risk  for  a  given  project 
can  be  profiled  in 
fifteen  elements 
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Risk  Elements 


Element 

I 

Low  Risk 

I 

High  Risk 

Low  Risk  High  Risk 

Requirements 

Sub-Str 

ategies  Sub-Str 

ategies 

Project  Office 

Contract 

Life  Cycle 
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Risk  and  Acquisition  Strategies 
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For  Example:  Specification  Risks 

Stable,  fully  defined,  unambiguous,  consistent,  complete, 
testable  software  requirements  are  rare. 

•  Some  requirements  are  firm  from  the  start 

•  Some  requirements  cannot  be  defined  until  other  things 
about  the  system  are  known 

•  Some  requirements  may  be  in  a  constant  state  of  flux  as 
technology,  off-the-shelf  product,  mission  needs  (or  the 
understanding  of  what  is  needed)  evolve. 

Trying  to  fully  define  software  requirements  too  early  or 
trying  to  limit  requirements  changes  in  a  changing 
environment  may  be  riskier  than  having  flexible  requirements. 

The  acquisition  strategy  needs  to  accommodate  the  degree 
to  which  requirements  can  or  should  change. 
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Well-defined,  complete, 
and  stable 


Incomplete  or  volatile 

Specification 


Well  defined  and  stable  Incomplete  or  volatile 

Reqmts 

§  Implement  strong  process  §  Flexible,  prioritized  and 

oversight  to  control  negotiated  requirements 

changes  §  Nimble  process  to 

manage  and 
communicate  changes 

Project 

Office 

§  Limited  oversight  required  §  Increased  need  for 

engineering  staff  to 
monitor  system 
design/progress 

Contract 

§  Consider  fixed  price  §  Avoid  completion 

contract  contracts  (use  Cost-plus 

services  contract?) 

§  Offer  incentives  for 
delivered  system 
performance 

Life  Cycle 

§  “Waterfall”  approach  §  Spiral  approach 

§  Favorable  terms  for  O&M  §  May  not  be  able  to 

may  be  defined  with  award  an  O&M  contract 

development  contract  better  understood 
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Well-defined,  complete, 
and  stable 


Selected  requirements  depend 
on  volatile  technology 


Specification 


Incomplete  or  volatile 


Well  defined  and  stable  Incomplete  or  volatile 

Reqmts 

§  Implement  strong  process  §  Flexible,  prioritized  and 

oversight  to  control  negotiated  requirements 

changes  §  Nimble  process  to 

manage  and 
communicate  changes 

Project 

Office 

§  Limited  oversight  required  §  Increased  need  for 

engineering  staff  to 
monitor  system 
design/progress 

Contract 

§  Consider  fixed  price  §  Avoid  completion 

contract  contracts  (use  Cost-plus 

services  contract?) 

§  Offer  incentives  for 
delivered  system 
performance 

Life  Cycle 

§  “Waterfall”  approach  §  Spiral  approach 

§  Favorable  terms  for  O&M  §  May  not  be  able  to 

may  be  defined  with  award  an  O&M  contract 

development  contract  better  understood 
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A1 


r 


A2 


Well-defined,  complete, 
and  stable 


Selected  requirements  depend 
on  volatile  technology 

Specification 


=i 


Incomplete  or  volatile 


Well  defined  and  stable  Strategy  A2  Incomplete  or  volatile 

Reqmts 

§  Implement  strong  process  •  Isolate  the  affected  §  Flexible,  prioritized  and 

oversight  to  control  requirements  so  the  negotiated  requirements 

changes  changes  are  obvious  §  Nimble  process  to 

manage  and 
communicate  changes 

Project 

Office 

§  Limited  oversight  required  .  Track  technology  §  Increased  need  for 

evolution  to  identify  engineering  staff  to 

commitment  point  monitor  system 

design/progress 

Contract 

§  Consider  fixed  price  •  Separately  price  §  Avoid  completion 

contract  unknown  contracts  (use  Cost-plus 

requirements  —  services  contract?) 

incentivize  low  cost  §  Offer  incentives  for 

delivered  system 
performance 

Life  Cycle 

§  “Waterfall”  approach  .  pian  and  budget  for  §  Spiral  approach 

§  Favorable  terms  for  O&M  changes  across  the  §  not  be  able  to 

may  be  defined  with  life  of  the  system  award  an  O&M  contract 

development  contract  better  understood 
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Next  Steps  in  Use  of  Sliders 

Validate  the  approach  and  the  set  of  sliders  by 
profiling  the  software  risk  in  selected  Army  programs 
using  the  sliders 

Show  how  each  program’s  current  acquisition 
strategy  relates  to  their  identified  software  risk 

Pilot  use  of  Guidelines  in  a  new  start 

Document  the  Guidelines 
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Contact  Information 


Ceci  Albert 
cca@sei.cmu.edu 
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